Silk Road forums
Support => Feature requests => Topic started by: envious on July 19, 2011, 05:10 pm
-
So I'm sure everyone has seen my other thread and know how much I hate escrow. The MAIN reason to this is because i am not comfortable putting thousands of dollars into a web persona that is a high profile target for LE. We have been chatting on the SILC channel about this and have come up with a wonderful solution to this problem. It will require a lot of coding, but i would happily donate for development, and I would hope other vendors would as well, as it protects us the most. I would happily use escrow if this system was created.
Outline:
Use a separate server for escrow. Why? The market server is public. Any and all trace attempts are going be targeted at this server. Use custom programming to have the escrow server communicate with the market server over torspace. This keeps our coins completely autonomous from the marketplace. What is the advantage to this? If LE ever traces the server and seizes it, the coins are not lost. But what if something happens to SR himself? Then the coins are sitting on a server with no one to send them out. Solution: We implement a dead man's switch, similar to the Wikileaks insurance file. There is a system where SR would need to login every couple days, and verify himself. If this does not happen, all funds are automatically distributed out to the backup wallet addresses. Okay, so the market server has been seized, can't they get the escrow server address off the market server? Possibly, I'm sure its all fully encrypted but we know LE can do ram dumps if they get to it while its powered on, which they most likely would as it's a server. Ideally, the dead man's switch would be triggered by the time they were able to trace the escrow server so it wouldn't matter.
Problems:
Preventing double spends: The two servers would need to be in constant sync. I'm sure this could be accomplished but I'm not sure how.
Secure communication between servers: If the market server was hacked, what is stopping the hacker from hijacking the TCP stream and telling the other server to send the entire escrow to himself? It would be necessary for the marketplace to be able to send instructions to the escrow server. This would take a very smart hacker but trust me they do exist.
Coins for orders still in transit: Who do they go to? Implement trust levels for proven and unproven vendors. Proven vendors get 100%. Unproven vendors could get a 50/50 split. Hopefully the customers have a backup way to communicate with vendors anyway, and then they can work it out between each other. This isn't ideal but its the best I can come up with.
This is simply a brainstorm at this point but it is a great idea. Please post any ideas for improvements, solutions, or any problems you may see in the system. :)
-
i agree that some kind of redundancy systems need to be in place.
-
This sounds great to me.
This is an issue that is gonna take some time to get together but I would put it next on the list of things to improve. :D
-
Can we get a cost estimate on setting this up? I would love to donate.
-
I don't know. It complicates the system, and you'd have to trust evem *more* software--and people--and how to ensure that whoever does the coding doesn't throw in a 'backdoor' they can access down the line.
That's one thing. My other concern is 'coins in transit' where 'proven vendors' get 100 per cent. I like the set up now, better. The buyer can release funds if he wishes, but it seems like you wish to eliminate escrow altogether here...or are you just saying they would be released immediately if there was a problem, and main server was compromised?
I don't really see the 'problem' with escrow anymore, because the way it is now, if you *are* a good, reliable seller, then buyers can lift escrow anyway. And we certainly don't want a system where poor or unreliable sellers wouldn't have the escrow 'incentive' to get the job done in a timely manner..
Right now, as it stands, if you have a good relationship with certain buyers, you just say--for example--"Phubai, I'll send you 20 dilaudids, send be 40 btc..." ( I see all kinds of 'special packages' lately, and system allows the straight sending of btc.. ) You get the btc, send me an encrypted pm saying they are on their way....you got the btc, I got the package in the mail. We still need to set up a way to add feedback. That's why I prefer to just finalize early, and that way you get btc as soon as shipment is made, and I still get to post the positive feedback for you... But this is only a one 2 one setup, between the buyer and the seller. So newbies still get the escrow, until they get comfortable with the seller.
I still think the foundation, the core of Silk Road, that makes it profitable and attactive, is it's escrow system. I get the concerns over LE takeover of site, and I certainly don't deny the temporary financial burden put on sellers by the escrow system, but it's the way it's set up, and it's protection for buyers is the attraction of the site. Separating funds is certainly worthy of discussion, but it has it's drawbacks, and you'd want to get a lot of input, from buyers as well as sellers.
-
No no phubai you are missing the point. The system would stay exactly how it is now. This is just a contingency plan that escrow would fall back on in case something bad happens. There would be no noticeable change to the average SR user because this all takes place behind the scenes. The buyer would be unable to release funds if this system was triggered because the marketplace would be down. You would have no access to your funds or orders. Not sure what you mean by lifting escrow? I don't think user to user transfer allows SR his cut. Also I would hope the same people would code it that coded the marketplace, so really you wouldn't have to trust anyone more than you already are. Yeah i know the in transit thing isn't ideal but I can't come up with anything better. Hopefully someone else can? Really it is no different then it is setup currently because the exact same people would be running it. It just decentralizes things and makes it safer. We sort of came up with this as a meet halfway solution that will allow escrow to be used and minimize the risk of funds being lost if anything ever happened. This just improves upon the escrows design.
-
What is being proposed is very similar to most high transactional e-commerce sites in functional separation of services.
Although what I do notice in your post is that instead of providing a solution to ensure funds aren't seized if the marketplace server goes down, you push your agenda of changes to the escrow system. If an repeat buyer does not receive a delivery from a new seller, the default resolution is not 50/50.
I agree with your proposals except for your comments on giving sellers more control over escrow.
-
I am not trying to push anything. If there was some other way for buyers to confirm delivery I would be all for it. But how can you confirm delivery with the marketplace down? It's neither fair for customer nor vendor to completely lose their money, so a 50/50 split seems the most fair solution to me. I'm trying to come up with improvements to the system that can make everyone happy, but people think i am just pushing my own agenda. This gives vendors NO control over escrow, its still 100% in SR's hands. I don't see what you are getting at rake. You need to keep in mind this system would be a one-time thing because if its ever activated, SR is gone for good. It is a contingency plan and that is it.
-
After a discussion with Envious I need to clarify that when he mentioned escrow, he actually meant a default resolution in the resolution center if the SR site is shutdown. I agree with his point here.
-
i think that the idea of a separate server that handles the funds in escrow and in our accounts that is offsite from the marketplace server and is only accessed by the market server is a great idea. that way if the market server is ever seized or shut down permanently, the returning of the account and escrow funds to your backup btc wallet could be triggered automatically by a dead mans switch on the funds server before access to the funds server occurred by whatever agency or person that seized or shut down the market server.
-
This is a really good idea and I don't think it would have to be that complicated.
Right now, we backup the wallets and database frequently on separate servers , so if the main server went down, we'd know the state of all open transactions and accounts and could pick back up where we left off on a new server, or refund everyone, split up escrow, etc. However, if someone were to somehow seize control of the server, they could send the bitcoins to an address they control and the backup would be useless. Storing the bitcoins on separate servers like you suggest would help protect us from this.
Great idea, it's on the to-do list :)
-
This is a really good idea and I don't think it would have to be that complicated.
Right now, we backup the wallets and database frequently on separate servers , so if the main server went down, we'd know the state of all open transactions and accounts and could pick back up where we left off on a new server, or refund everyone, split up escrow, etc. However, if someone were to somehow seize control of the server, they could send the bitcoins to an address they control and the backup would be useless. Storing the bitcoins on separate servers like you suggest would help protect us from this.
Great idea, it's on the to-do list :)
+1
-
^5
-
Yay! I love Silk Road's reaction to good ideas from users: "sounds good, we'll do it ASAP". :)
Considering how often the mining pool sites (and some BTC banking and trading sites) are being attacked, hacked, DDOS, etc. it would make eminent sense to have a separate place where the money records reside in case of an attack. Bravo again for SR.
Since I'm sure SR will read this thread I'll put my other concern here: I'm trying to talk a friend of mine into selling
on SR. In reviewing some sellers pages it occurred to me that you can easily see who is doing the real volume by the # of transactions and looking up the "item". I'd propose changing it so that it works exactly as it does now until you reach 100 transactions. Then it just says "over 100 transactions" forever and lists the most recent 10 or 20 (I prefer 20) feedbacks for that seller. That way no one who doesn't have access to the server knows anyone's true sales volume. I'm not a seller, but if I was, this would be very important to me. Thoughts?